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1.  INTRODUCTION 

An  important  component  of  the  Packet  Radio  project  is  the 
station  software,  providing  a  variety  of  control,  coordination 
and  monitoring  functions.  BBN"s  role  in  developing  this  software 
is  to  specify,  design,  implement  and  deliver  programs  which 
perform  these  functions. 

During  this  quarter  important  progress  was  made  on  design 
details  in  the  processing  of  Local  Repeater  On  Packets  (LROPs) 
and  Performance  Data  Packets  (PDPs) .  These  and  other  meetings 
and  negotiations  are  covered  in  section  2,  especially  noting 
important  demonstrations  of  mini-gateways.  Transmission  Control 
Program  (TCP) ,  and  down  line  loading  of  Packet  Radio  units  by  the 
station.  Section  2  also  covers  publications,  including  two 
important  Internet  Experimenters"  Notes  on  routing  and  flow 
control. 

Section  3  deals  with  the  Packet  Radio  network  area, 
especially  station  issues,  and  is  dominated  this  quarter  by  the 
completion  of  coding  of  the  Channel  Access  Protocol  (CAP)  version 
5  Labeler  process.  The  CAP  5  Labeler  has  been  partially  tested 
and  debugged,  and  is  now  working  in  the  BBN  PR  net  testbed. 
Additional  progress  of  lesser  import  was  made  on  the  PR  down  line 
load  process,  the  cross-radio  debugger,  and  operating  systems  ELF 
and  MOS. 

Section  4  covers  the  installation  of  a  new  service  host 
machine  for  TCP  testing  and  development.  Also  in  section  4  is  a 
discussion  of  improvements  in  the  robustness  of  mini-gateways, 
and  demonstrations  of  mini-gateways. 

Section  5  reports  on  a  number  of  hardware  issues  which 
evolved  during  this  quarter.  Of  most  significance  is  the 
conclusion  of  the  investigation  into  problems  with  Error  Control 
Units  (ECUs)  . 
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2.  MEETINGS ,  TRIPS ,  PUBLICATIONS 
2.1.  Meetings  and  Trips 

A  number  of  meetings  this  quarter  furthered  technical  design 
and  negotiation  in  several  areas.  A  software  review  meeting  for 
the  Improved  Packet  Radio  (actually  held  the  last  week  of  the 
preceding  quarter)  was  attended  by  BBN  personnel.  Here  the 
design  of  the  IPR  operating  system  was  fine-tuned  to  best  support 
project  needs. 

BBN  personnel  were  on  site  at  SRI  for  pre-demonstration 
preparations  the  week  before  the  March  27  demonstration  of  the 
network,  as  well  as  during  the  demonstration.  At  this  event  the 
new  PR  down  line  load  capability  was  demonstrated,  as  well  as  TCP 
functions  and  general  CAP  4.9  operation. 

A  technical  design  meeting  of  CAP  5  implementers,  held  April 
9-11  at  ARPA  facilities  in  Washington,  was  also  attended  by  BBN 
personnel.  Here  details  of  Local  Repeater  on  Packet  (LROP)  and 
Performance  Data  Packet  (PDP)  processing  were  resolved.  Schedule 
issues  were  also  negotiated,  and  packet  formats  specified. 

Station  resources  will  be  freed  by  having  either  a  measurement 
process,  or  cross-radio  PR  debug  and  PR  down  line  load  processes, 
but  not  all  three,  resident  simultaneously.  The  most  important 
improvement  which  CAP  5  will  achieve  is  the  change  to 
point-to-point  routes,  which  will  alleviate  the  congestion  now 
seen  at  the  station's  PR  destined  for  the  resident  gateway. 

We  hosted  an  Internet  meeting  in  mid-May,  at  which  we 
demonstrated  gateway  alternate  routing.  Gateways  at  BBN  were 
configured  such  that  two  paths  existed  between  a  TIU  on  the  BBN 
Research  Computer  Center  network  and  a  TIU  on  the  SRI  Packet 
Radio  network.  When  one  path  was  broken,  by  halting  one  of  the 
gateways  on  that  path,  traffic  was  automatically  routed  by  the 
gateways  over  the  alternate  path.  This  demonstrates  the 
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operational  function  of  the  new  gateway  alternate  routing 
strategy  presented  in  our  previous  QPRs.  (See  especially  OPR 
17.) 

2.2.  Publications 

Three  important  publications  were  released  this  quarter. 

PRTN  174  -  revision  7,  "Packet  Radio  Network  Station 
Labeling  Process" 

This  PRTN  has  been  updated  to  include  the  latest 
modifications  to  the  Labeler  as  modified  for  CAP  4.9. 

Internetwork  Experimenters'  Note  (IEN)  86,  "Extended 
Internet  Routing" 

IEN  87,  "Internet  Flow  and  Congestion  Control” 

These  two  IENs  present  designs  in  dealing  with  complex 
issues  in  internet  traffic  handling.  While  the  latter  attempts 
to  prevent  collapse  of  performance  when  offered  traffic  threatens 
to  exceed  the  capacity  of  internet  components,  the  former 
provides  mechanisms  for  properly  delivering  traffic  while  the 
network  is  constrained  by  access  control  requirements.  IEN  87 
covers  more  than  just  access  control,  however?  it  presents  a 
method  of  providing  routing  which  recognizes  qualitative 
differences  among  links.  Access  control  implies  just  keeping 
"bad"  traffic  off  a  given  link?  extended  routing  provides  that 
and  in  addition  allows  users  to  avoid  links  with  certain 
characteristics  for  the  users'  own  reasons  as  well,  or  to  weight 
against  the  use  of  those  links. 

We  also  contributed  additional  material  to  the  Packet  Radio 
project  bibliography  this  quarter. 
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2.3.  Negotiations  and  Informal  Documents 
2.3.1.  Periodic  route  erasure 

PR  route  handling  was  partially  redesigned  at  the  PRWG 
meeting  last  quarter,  January  22-24.  In  talking  about  the  new 
approach  afterwards  at  BBN  we  found  an  unfortunate  impact  on  CAP 
5  routing,  as  noted  in  QPR  17.  As  discussed  there,  a  small 
change  to  PR  route  erasure  has  important  consequences.  During 
this  quarter  resolution  was  reached  on  this  issue,  as  described 
below.  For  context,  the  statement  of  the  issues  is  also 
presented  again  here. 

Decision  at  PRWG  Meeting 

-  PR  only  erases  a  route  if  it  needs  the  slot  for  a  new  route. 

-  PR  keeps  track  of  route  usage  by  a  time  stamp  and  will  not 
erase  the  route  until  its  lack  of  use  goes  over  a  certain 
threshold. 

-  PR  will  erase  the  route  which  has  been  used  least  recently  if 
a  slot  is  required. 

Problem 

If  the  TIU  is  only  interested  in  sending  packets  to  a  few 
destinations  some  routes  may  rarely,  if  ever,  get  garbage 
collected.  Since  the  CAP5  station  will  try  to  reassign  routes 
traveling  over  a  bad  link,  rather  then  simply  erasing  them,  a 
significant  portion  of  station  resources  may  be  tied  up  keeping 
track  of  and  updating  old,  unused  routes. 

Suggested  approach 

We  suggest  that  two  thresholds  be  used  for  decisions  about 
route  discarding.  The  first,  and  current,  is  the  minimum  time 
before  the  PR  can  optionally  garbage  collect  an  unused  route  slot 
for  a  new  route.  Its  purpose  is  to  provide  slots  for  new  traffic 
so  the  traffic  won't  be  forced  to  funnel  through  the  station 
which  is  both  slow  and  costly. 
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The  second  threshold  is  the  maximum  time  an  unused  route 
should  be  allowed  to  remain  in  the  PR's  route  table.  After  this 
threshold  is  reached  route  erasure  is  mandatory  regardless  of 
need  for  reuse  of  the  slot.  The  purpose  of  the  second  threshold 
is  to  reduce  control  traffic  and  route  computation  by  the 
station.  The  mandatory  route  erasure  would  be  a  much  longer  time 
interval  than  the  optional  route  erasure.  Perhaps  on  the  order 
of  minutes  for  optional,  and  on  the  order  of  hours  for  mandatory. 

Why  it  works 

The  station  won't  realize  the  route  has  been  erased  because 
the  mandatory  erasure  is  based  on  time  since  last  use  rather  than 
time  since  creation,  and  will  retain  knowledge  of  the  route  until 
there  is  a  problem  on  one  of  the  links.  At  that  time  it  may 
choose  to  send  out  a  new  route.  It  will  then  be  informed  that 
the  route  is  absent  from  the  PR  and  will  erase  the  route  from  the 
station's  own  table. 

This  approach  limits  the  useless  control  traffic  to  one 
exchange.  If  the  route  hadn't  been  removed,  the  station  would 
continue  to  compute  new  routes  for  the  PR. 

Resolution 

The  eventual  resolution  of  this  problem  occurred  in  the 
middle  of  March,  and  is  as  follows: 

1)  A  PR  will  erase  a  PTP  route  1  hour  after  the  route's  last  use 
if  the  PR  can  open  an  SPP  connection  to  the  station.  The  PR 
will  send  a  reason  dependent  PDP  over  the  SPP  connection 
indicating  that  the  route  is  erased. 

2)  Unlabeled  PRs  maintain  link  quality  tables  through  normal  LROP 
processing.  As  soon  as  the  PR  is  labeled,  the  PR  will  send  a 
PDP  to  the  station  reporting  current  link  qualities. 
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3)  Raw  transmit  counts  will  be  included  in  all  PDPs.  These  will 
be  used  to  evaluate  the  PRs'  capacity,  and  when  understood, 
may  impact  routing  algorithms  to  aid  in  congestion  control. 

4)  PRs  will  immediately  generate  a  link  quality  chance  PDP  if  the 
link  quality  falls  below  a  certain  level. 

5)  PRs  will  not  immediately  report  the  removal  of  a  route  to  make 
room  for  another,  but  wait  until  a  PDP  is  generated  for 
another  purpose. 

6)  The  Labeler  will  send  route  interrogation  packets  to  correlate 
its  understanding  of  current  routes  with  those  actually 
distributed.  We  must  still  consider  the  impact  of  patching 
the  Gateway  PR  to  accept  some  large  number  of  routes  (30-50)  . 
This  will  require  more  then  one  packet  from  the  Gateway  to 
report  all  the  routes. 

7)  There  will  be  no  indexing  into  the  PR's  route  table.  (This 
has  no  direct  bearing  on  the  PTP  route  erasure  but  was 
negotiated  at  the  same  time.) 

2.3.2.  Miscellaneous  negotiations 

Many  informal  negotiations  this  quarter  revolved  around  the 
resolution  of  CAP  5  design  issues.  In  preparation  for  the  CAP  5 
meeting  (see  section  2.1),  we  developed  the  rough  plan  for  a 
mechanism  to  support  better  alternate  routing.  This  consists  of 
a  "help"  packet  sent  by  a  mobile  PR  which  can  no  longer  send  (get 
acknowledged)  its  traffic.  Unfortunately,  the  cost  of 
maintaining  information  sufficient  to  get  traffic  addressed  TO 
the  mobile  PR  delivered  is  high.  We  also  prepared  a  list  of  CAP 
5  issues  needing  resolution. 

We  reviewed  data  from  UCLA  which  showed  some  loss  of 
Cumulative  Statistics  (CUMSTAT)  packets  from  PRs  and  TiUs  during 
measurement  experiment  runs  UCLA  conducted.  We  concluded  that 
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excessive  congestion  in  the  network  could  explain  all  the  effects 
shown,  and,  since  we  know  there  is  congestion  difficulty  with  CAP 
4  protocol,  we  assume  that  that  is  the  proper  explanation. 

An  internal  document  was  drafted  this  quarter,  explaining 
how  to  deliver  station  software  to  remote  sites  using  the 
cross-internet  debugger,  XNET.  This  will  help  streamline  the 
delivery  of  station  software  in  the  future,  permitting  more  rapid 
and  reliable  operational  support  in  this  area. 

We  continued  the  informal  investigation  into  PR  radiation 
hazards,  begun  last  quarter.  We  sent  further  figures  on  the  PR" s 
microwave  radiation  level,  and  its  relation  to  United  States  and 
Russian  safety  standards,  to  Collins  and  ARPA.  It  would  appear 
that  whether  safety  standards  are  violated  by  workers  near  PRs  is 
arguable;  the  radiation  is  neither  negligible  nor  obviously  a 
serious  danger. 

In  early  April  we  hosted  a  visit  from  Professor  Dimitri 
Bertsekas  of  MIT,  at  which  we  discussed  his  "contingency"  routing 
algorithms.  These  seek  to  establish  a  new  path  to  a  common 
destination  when  links  in  the  network  fail.  We  talked  about 
their  features  and  their  possible  applicability  to  the  Packet 
Radio  net.  We  received  from  him  a  paper  on  his  design, 
"Algorithms  for  Optimal  Routing  of  Flow  in  Networks",  another 
related  to  Professor  Gallager's  routing  scheme  (see  QPR  16, 
section  2.1.4),  "Validation  of  Algorithms  for  Optimal  Routing  of 
Flow  in  Networks",  and  a  copy  of  the  thesis  of  Michael  Hluchy j , 
one  of  Professor  Gallager"s  students,  "Connectivity  Monitoring  in 
Mobile  Packet  Radio  Networks".  We  considered  these,  hut  in  each 
case  one  or  more  of  the  features  of  the  Packet  Radio  net  which 
make  the  net  attractive,  also  make  it  intractable  by  the 
theoretical  mechanisms  considered. 
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These  features  are  primarily: 

(1)  potential  link  between  any  two  nodes, 

(2)  moderately  frequent  disruption  of  each  of  several  links 
(especially  due  to  mobility  of  PRs) , 

(3)  point-to-point  routing  desired,  rather  than  concentration  to 
or  from  any  one  point, 

(4)  importance  of  relatively  speedy  repair  of  broken  routes, 
though  absolute  optimality  is  unnecessary, 

(5)  inability  of  nodes  (PRs)  to  perform  large  computational 
tasks,  and/or  to  store  large  volumes  of  data,  and 

(6)  interconnection  of  many  logical  links,  due  to  use  of  shared 
radio  broadcast  channel,  making  channel  bandwidth  used  for 
control  on  various  links  more  costly. 

In  mid-May  a  PR  failure  (see  section  5)  prompted  us  to  note 
certain  problems  with  the  PR  software.  The  "hardware  straps" 
diagnostic  seems  to  assume  certain  RAM  memory  locations  -  not 
initialized  by  the  program  -  contain  valid  data.  If  the 
diagnostic  is  run  with  different  data  than  assumed,  it  does  not 
execute  properly.  This  was  reported  to  Collins.  Also  reported 
was  a  problem  with  the  text  of  LROPs,  but  since  this  problem 
could  not  be  reproduced  after  repair  of  our  failed  PR,  we  ascribe 
it  to  hardware  malfunction. 

We  negotiated  two  PDP  issues  with  Collins  personnel.  In 
one,  we  discussed  whether  receipt  of  a  down  line  load  request 
from  a  neighbor  PR  should  constitute  a  new  PDP  "reason"  entry. 

It  was  resolved  that  the  present  mechanism,  which  includes  a 
reason  entry  for  unlabeled  neighbors,  contains  sufficient  data  to 
also  convey  the  down  line  load  request,  with  a  slight 
reformatting.  The  second  issue  regards  when  PDPs  may  be  sent 
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without  connection  close  (PIN)  indication.  One  suggestion  is 
that  PDPs  be  sent  as  "normal"  (versus  SYN/FIN)  if  either  the 
receive  or  the  transmit  sides  are  open.  Presently  only  the 
transmit  side  is  tested.  As  this  quarter  closed,  this  issue  is 
still  under  discussion.  The  important  issue  here  is  that  the 
station  and  the  PR  not  become  confused  about  the  state  of  the 
connection  between  them.  If  they  get  out  of  synchronization, 
undesirable  delays  may  be  incurred  and  control  traffic  may  be 
lost.  We  are  also  in  contact  with  Collins  about  actual  debugging 
of  PDP  transmission  via  SPP. 
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3.  THE  PACKET  RADIO  NETWORK 

3.1.  Station  Programing  and  Testing 

3.1.1.  ELF,  MOS 

Three  improvements  to  the  ELF  operating  system  were  made 
this  quarter.  The  first  is  that  ELF  now  jumps  into  the  internet 
bootstrap  code  after  system  errors.  This  will  allow  the  crashed 
ELF  memory  image  to  then  be  accessed  remotely  via  XNET,  the 
cross-internet  debugger,  with  no  manual  action  at  the  station 
site.  This  will  aid  debugging,  which  was  hampered  by  the  fact 
that  programming  staff  could  not  connect  to  the  ELF  once  it 
crashed  without  co-ordination  with  on-site  personnel. 
Additionally,  this  permits  another  step  we  have  taken  to  aid 
debugging;  a  command  file  has  been  written  which  allows  an 
inexperienced  operator  to  dump  the  ELF  memory  image  into  a 
TOPS- 20  file  after  system  errors. 

Second,  the  ELF  system  has  been  modified  to  not  use  XNET 
debugger  packets  destined  for  the  Packet  Radio  net  to  identify 
itself.  To  preserve  software  interchangeability,  ELF  does  not 
have  its  network  address  compiled  into  the  program.  Instead,  it 
used  to  listen  for  the  first  XNET  packet  it  received,  and  use  the 
address  of  the  destination  specified  in  that  packet  as  its  own 
address.  Unfortunately,  the  new  process  used  by  SRI  to  load 
Terminal  Interface  Units  (TIUs)  on  the  PR  net,  uses  XNET  to 
perform  the  load.  If  a  fresh  station  first  receives  TIU  load 
packets,  the  address  ELF  takes  as  its  own  is  incorrect;  in 
particular,  the  network  number  is  that  of  the  PR  net,  not  the 
ARPANET.  Thus  further  communication  via  XNET  fails,  and  in 
particular  the  TIU  load  attempt  fails.  ELF  was  modified  to  take 
its  address  only  from  packets  not  destined  to  a  PR  net,  which 
preserves  the  interchangeability  and  solves  the  problem. 
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Third,  a  bug  in  ELF's  IMPll-A  interface  driver  was  found  and 
fixed.  This  remedies  a  long  standing,  obscure  problem  in  its 
input/output  system. 

Also  a  bug  in  MOS  was  fixed  this  quarter,  in  the  teletype 
device  tables.  MOS  is  the  operating  system  used  in 
mini-gateways. 

We  also  worked  on  station  software  configuration  to  support 
the  March  27  demonstration  (see  section  2.1) .  This  involved 
adjusting  system  resource  allocations  to  provide  good  service  for 
the  loading  that  was  anticipated. 

3.1.2.  Labeler 

The  CAP  4.9  Labeler  was  revised  this  quarter  to  suppress 
labeling  attempts  instigated  by  ROPs  containing  down  line  load 
requests.  Since  the  PR  was  not  running  CAP  protocol,  such 
attempts  were  doomed  to  fail  anyway.  This  would  also  cure  a 
problem  reported  by  SRI,  wherein  the  Labeler  went  deaf  for  a 
period  of  many  minutes  to  a  PR  which  was  being  down  line  loaded 
but  taking  a  long  time  for  the  load.  With  this  particular 
problem,  however,  it  appears  that  bugs  in  the  PR  CAP  4.9  code 
were  to  blame. 

Coding  of  the  CAP  5  Labeler,  which  requires  extensive 
modifications  to  the  CAP  4.9  version,  were  completed  and  tested 
this  quarter.  The  size  of  the  Labeler  has  actually  decreased, 
which  is  good  news  considering  the  tightness  of  station  memory. 
This  decrease  is  due  partly  to  removal  of  old  routines  pertaining 
only  to  CAP  4  logic,  and  partly  to  alteration  of  data  structures 
to  provide  more  compact  storage  and  cheaper  referencing.  The 
savings  is  one  page  of  memory.  Although  future  enhancements  may 
reuse  this  page,  the  decrease  is  an  encouraging  fact. 
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Some  CAP  5  Labeler  debugging  was  performed  on  the  PDP-10 
this  quarter,  because  the  PDP-11  was  in  use  for  Internet  meeting 
demonstration  preparations  (see  section  2.1).  The  routines 
dealing  with  route  computation  were  extracted  and  modified  to 
PDP-10  BCPL,  and  debugged  with  BDDT.  Although  these  routines 
were  the  only  ones  which  could  be  made  machine- independent  (since 
others  performed  extensive  input/output  manipulations) ,  debugging 
them  on  the  PDP-10  used  the  time  well  which  would  otherwise  have 
caused  a  slip  in  delivery.  This  is  due  to  the  complexity  of 
these  routines,  arising  largely  from  the  need  to  carry  not  only 
number  of  hops  but  also  accumulated  route  quality  through  the 
computations. 

The  CAP  5  Labeler  is  now  working  in  the  BBN  PR  net  testbed. 
It  labels  both  PRs,  receives  PDPs  on  both  specific  and  listening 
connections,  and  generates  PDP  requests  when  appropriate.  As 
this  quarter  draws  to  a  close,  the  plan  is  to  now  move  to  further 
testing  in  the  SRI  net  with  its  larger  population  of  PRs.  Since 
CAP  5  supplies  information  not  previously  available,  we  also  plan 
to  add  new  manual  entry  commands  to  the  Labeler  to  permit  the 
station  operator  to  make  use  of  this  data. 

In  summary,  CAP  5  provides  the  following  new  features: 

+  LROPs  assess  radio  link  quality  locally 

+  good  neighbor  table  (GNT)  in  each  PR  stores  its  current 
connectivity 

+  PRs  use  GNT  to  provide  more  reliable  alternate  routing 

+  PRs  report  connectivity  (GNT)  and  exception  conditions  to 
station  via  Performance  Data  Packets  (PDPs) 

+  PDPs  are  sent  via  reliable  protocol  (SPP) 

+  Labeler  uses  PDPs  to  maintain  a  station  table  of  link 
qualities 
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+  Labeler  can  request  a  PDP  when  necessary 

+  Labeler  employs  link  qualities  as  well  as  route  length  (number 
of  hops)  to  assign  routes 

+  failure  of  traffic  is  reported  in  a  PDP,  resulting  in  timely 
assignment  of  a  better  route  by  the  Labeler 

3.1.3.  PR  down  line  load  process 

During  this  quarter,  a  bug  in  PR  down  line  loading  was 
fixed,  and  one  performance  improvement  was  made.  An  additional 
problem  in  down  line  loading  was  found  to  relate  to  PR  code,  and 
was  cured  by  a  later  release  by  Collins. 

The  bug  in  the  station's  PRLOAD  process  was  a  failure  to 
correctly  detect  the  connection  process'  occasional,  temporary 
inability  to  open  a  connection  to  a  loader  PR,  a  PR  through  which 
the  final  hop  of  a  down  line  load  is  performed.  This  could  occur 
when  the  connection  process  was  momentarily  too  busy  —  or  out  of 
connection  slot  resources  —  to  honor  PRLOAD's  request  for  a 
connection.  The  result  was  a  hangup  of  down  line  loading.  The 
problem  was  fixed  by  improving  the  connection  handling  error 
routines  in  PRLOAD. 

The  improvement  to  PRLOAD  performance  resulted  from  a  more 
detailed  consideration  of  the  handshaking  which  occurs  in  down 
loading  the  station's  PR.  As  discussed  in  QPR  17,  there  is  no 
loader  PR  when  loading  the  station's  PR.  therefore,  there  is  no 
SPP  connection.  It  had  been  thought  that  with  only  a  raw 
(non-SPP)  connection,  PRLOAD  might  overrun  the  connection  process 
or  the  station's  PR,  feedinq  it  down  line  load  packets  faster 
than  they  could  be  processed.  Closer  consideration,  however, 
revealed  that  with  a  connection  window  size  of  one,  the 
connection  process  will  not  accept  from  PRLOAD  (and  thus  cannot 
transmit  to  the  PR)  another  packet  until  the  previous  packet  has 
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been  transmitted  successfully.  Removing  the  rate-limiting  timer 
from  PRLOAD  now  permits  loading  the  station's  PR  in  only  three 
seconds,  compared  to  four  seconds  for  a  PR  one  hop  from  the 
station,  and  nine  seconds  for  the  old  method  of  loading  the 
station's  PR. 

Also  during  this  quarter  we  sent  documents  to  SRI, 
describing  various  aspects  of  down  line  loading  and  in  particular 
how  to  use  the  support  software  to  place  a  TOPS- 20  disk  file  of 
PR  software  on  the  station  disk.  It  is  our  hope  and  expectation 
that  Collins  or  SRI  staff  will  be  available  to  follow  these 
procedures,  thus  preventing  delivery  of  PR  code  to  station  disk 
from  relying  on  availability  of  BBN  staff. 

3.1.4.  XRAY  cross-radio  debugger 

Joint  debugging  with  Collins  this  quarter  permitted  the 
release  of  a  completed  new  version  of  the  cross-radio  debugger, 
XRAY.  This  version  uses  command  packets,  performs  multiple  alter 
memory  (AM)  and  multiple  display  memory  (DM)  commands  properly, 
and  employs  20-bit  addresses  to  support  IPR  memory  size.  This 
version  also  includes  a  new  command,  the  DL  command,  which  forces 
the  target  PR  into  down  line  load  mode.  The  delivery  of  this 
version  of  XRAY  included  updated  documentation. 

A  command  to  send  an  "initialize"  packet  to  the  target  PR 
was  tried.  This  packet  commands  the  PR  to  perform  an 
initialization  sequence  similar  to  that  resulting  from  an 
operator  pushing  the  "INIT"  button  on  the  PR  manually.  The  code 
in  XRAY  to  permit  this,  however,  bumped  the  XRAY  memory 
requirements  across  a  page  boundary.  The  new  XRAY  would  require 
slightly  over  one,  and  therefore  two,  pages  of  station  memory. 

The  station  memory  resource  is  in  short  supply;  also,  SRI 
commented  that  the  new  DL  command  will  obviate  the  need  for  a 
remote  initialize  command.  Consequently,  the  "initialize" 
command  was  not  retained  in  XRAY. 
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3.2.  Support 

During  this  quarter  we  made  a  preliminary  investigation  of 
modifying  the  BBN  "PRU"  program  to  use  a  Pluribus  tip  (ptip) 
line.  This  would  allow  Collins  to  debug  BBN  PRs  remotely  without 
having  to  borrow  one  of  the  scarce  direct  terminal  lines  on  a 
service  host.  The  BBN  PRU  program  was  derived  fairly  simply  from 
the  original  PRU  program  written  at  SRI,  but  conversion  to  use 
PTIP  line(s)  is  significantly  more  complex.  The  host-PTlP  dialog 
for  line  allocation,  buffer  management,  and  especially  for  speed 
selection  is  significantly  more  complex.  Since  these  operations 
are  scattered  throughout  the  PRU  program,  a  relatively  tricky  and 
large  modification  is  necessary.  Also,  execution  of  the 
host-PTIP  dialogue  requires  that  the  job  run  with  certain 
privileges  enabled,  and  letting  remote,  non-BBN  personnel  run  a 
job  so  enabled  is  likely  to  encounter  administrative  objections 
from  computer  center  staff.  Nevertheless,  the  modification 
appears  feasible  if  programmer  time  is  available. 

Another  support  activity  this  quarter  has  been  delivering  PR 
CAP  software  to  station  disks  at  SRI  and  BBN.  The  following 
chart  summarizes  these  deliveries. 

CAP  to  to  to  tape 

version  BBN  SRI  cassette 

4.9.5 

4.9.6 

4.9.7 

4.9.8  X 

4.9.9 

5.0.0  X 

These  deliveries,  of  course,  are  in  addition  to  regular 
deliveries  of  station  software. 

Also  this  quarter  we  created  a  directory  on  BBN  system  C, 
for  SRI  to  use  in  exercising  TCP. 
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4.  INTERNETWORKING 

4.1.  Transmission  Control  Program  (TCP) 

During  this  quarter  important  strides  were  taken  in 
providing  a  more  practical  environment  for  developing,  debugging, 
testing  and  exercising  TCP  and  Internet  Protocol.  This  is  a 
TOPS- 20  system,  now  named  BBNF.  TCP  version  4  has  been  brought 
up  on  this  machine,  on  which  arrangements  with  ARPA  have  been 
made  to  provide  very  significant  amounts  of  stand  alone  test 
time.  Bringing  up  TCP  4  is  considered  to  be  part  of  the 
acceptance  testing  of  the  machine. 

The  first  connections  between  a  Terminal  Interface  Unit 
(TIU;  the  ALTA-COMA  TIU  at  BBN  in  particular)  and  BBNF,  running 
TOPS-20  release  3A  with  TCP  and  TELNET  protocols  in  the  monitor, 
were  made  this  quarter.  Having  these  protocols  handled  in  the 
monitor  provides  faster  service  to  the  user  and  requires  less 
overall  time  for  the  same  results.  The  operation  of  connections 
demonstrates  a  high  degree  of  accomplishment  toward  the  goal  of 
providing  monitor  resident  TCP  and  TELNET  to  other  sites.  As 
this  quarter  closed,  the  closing  code  (no  pun  intended!)  for  TCP 
virtual  terminals  is  in  final  stages  of  debugging;  completion  of 
TVT  debugging  is  anticipated  early  next  quarter. 

4.2.  Gateways 

Elaborate  testing  and  demonstration  of  mini-gateway 
functions  was  performed  this  quarter.  First  was  a  complex  test 
at  SRI.  The  configuration  was  as  follows. 

(1)  The  mini-gateway  was  run  in  the  SRI  PDP-11/34  as  a  host  on 
the  ARPANET  and  on  the  Packet  Radio  net. 

(2)  The  station,  with  gateway  and  TCP,  was  run  in  the  SRI 
PDP-11/40  as  a  host  on  the  Packet  Radio  net  only. 

(3)  The  station  was  then  disconnected  from  the  ARPANET. 
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Three  resulting  data  paths  were  demonstrated,  as  follows. 

(1)  Users  at  SRI  were  able  to  connect  to  STACON,  operator's 
terminal  control  module  in  the  station,  from  the  TCP  at  BBNC, 
via  the  mini-gateway  and  the  TCP  in  the  station. 

(2)  Users  could  also  connect  to  STACON  from  a  Terminal  Interface 
Unit  (TIU)  on  the  SRI  Packet  Radio  net,  through  the  TCP  in 
the  station. 

(3)  TIU  users  could  also  connect  through  the  mini-gateway,  and 
from  there  through  the  TCP  in  the  station,  to  STACON. 

Later  this  quarter,  in  mid-March,  we  demonstrated  the 
mini-gateway,  running  in  a  PDP-11/40  at  BBN,  connected  between 
the  ARPANET  and  the  BBN  Research  Computer  Center  (RCC)  network. 

Problems  surfaced  in  the  robustness  of  the  mini-gateway  to 
withstand  errors  on  the  1822  interface  ready  line.  The 
mini-gateway  was  modified  to  withstand  such  errors,  and  tested  in 
two  ways.  First,  the  cable  between  the  IMPll-A  (the  PDP-ll's 
1822  interface)  and  the  IMP  was  plugged  and  unplugged.  Secondly, 
the  mini-gateway  was  further  tested  by  running  two  Internet 
traffic  streams  through  it  for  several  hours. 

Various  versions  of  the  mini-gateway  were  released  this 
quarter:  the  version  demonstrated  at  SRI,  and  the  modified 
version  resilient  to  ready  line  errors;  also  SATNET/ARPANET 
mini-gateways,  which  now  support  alternate  routing  and  run  on  the 
smaller  and  more  efficient  MOS  operating  system.  We  also 
delivered  to  SRI  a  station  whose  gateway  is  configured  to  run 
only  on  the  Packet  Radio  net,  ignoring  the  station's  ARPANET 
connection,  which  is  still  used  for  debugging  and  station  PR 
software  delivery. 

Gateway  functions  were  also  demonstrated  prominently  at  the 
Internet  meeting,  which  is  described  in  section  2.1. 
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5.  HARDWARE 

5.1.  Error  Control  Units 

The  Error  Control  Units  (ECUs)  manufactured  by  ACC  arrived 
at  BBN  for  testing  and  diagnosis  of  compatibility  problems  last 
quarter.  Some  problems  were  found  and  fixed,  but  proper 
operation  was  not  yet  achieved.  Early  this  quarter  we  hosted  a 
visit  by  ACC  engineers  to  iron  out  the  difficulties.  Severe 
pulse  reflections  from  a  point  where  two  cables  met  were  found  to 
be  confusing  the  ECU.  Although  the  IMPll-A  (PDP-11  interface) 
and  Pluribus  interface  worked  satisfactorily  with  this,  the  ECU 
is  more  sensitive.  ACC  engineers  installed  a  smoothing  circuit, 
which  eliminated  all  errors.  To  test  the  result,  station 
software  was  loaded  and  run,  through  the  pair  of  ECUs,  both 
connected  to  the  Pluribus  and  to  an  ARPANET  516  TIP.  The  ECUs 
have  been  shipped  to  SRI,  per  ARPA's  request,  now  that  the 
problems  are  solved. 

5.2.  Packet  Radio  Units 

A  few  hardware  failures  occurred  in  the  BBN  PRs  this 
quarter,  requiring  on-site  work  by  Collins  engineers  and  some 
module  swapping,  under  special  one-time  permission,  by  BBN 
personnel.  PR  number  1  suffered  a  DMA  module  failure,  which 
first  gave  symptoms  looking  like  a  memory  failure  in  the  other 
PR.  Later,  a  bad  transmit/receive  switch  in  PR  number  1 
necessitated  dropping  the  use  of  the  PRs  from  the  Internet  demo. 
Both  PR  number  1  and  PR  number  2  each  suffered  I/O  channel  card 
failures. 

Both  PRs  were  upgraded  with  EPR  Operating  System  version  2 
PROM  boards,  and  aligned  by  Collins  personnel  for  optimal  radio 
performance.  Down  line  loading  was  enabled  in  both  PRs, 
permitting  local  testing  of  the  PRLOAD  station  software  and 
faster  recovery  from  PR  software  crashes. 
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The  two  Packet  Radio  Digital  Units  (PRDUs)  are  no  longer 
needed,  since  the  EPRs  are  now  functional.  The  PRDUs  and 
associated  gear  were  returned  to  Collins.  We  also  corresponded 
with  Collins  regarding  the  radiation  pattern  and  Q  of  the 
standard  PR  antenna.  Detailed  information  they  supplied  helped 
us  to  evaluate  possible  microwave  radiation  safety  hazards,  as 
discussed  in  section  2.3. 

5.3.  PDP-11/34  Cache 

As  reported  last  quarter,  SRI  had  raised  a  question  about 
the  cache  in  the  PDP-11/34,  used  at  SRI  and  planned  for  use  at 
Fort  Bragg.  The  question  involves  a  possible  lack  of 
"transparency",  in  that  the  ELF  operating  system  may  need  to 
execute  certain  instructions  to  enable  the  cache,  and  to  field 
interrupts  from  the  cache. 

We  requested  further  technical  details  from  SRI,  since  the 
cache  was  one  chosen  by  them  and  not  a  component  of  the  standard 
Packet  Radio  station  as  specified  by  BBN.  Upon  receiving  this 
information,  we  deduced  that  the  cache  is  the  standard, 
transparent  cache  and  does  not  require  modifications  to  the 
station  software. 

5.4.  Station  PDP-lls 

The  BBN  station  PDP-11  number  1  suffered  a  CPU  failure, 
which  was  repaired  by  DEC,  by  replacing  the  data  path  board. 

Both  PDP-lls  were  unavailable  for  a  moderate  interval  this 
quarter  while  recabling  was  performed  in  preparation  for  the 
mini-gateway  demonstration  March  16. 

The  Collins  PDP-11/34  is  now  operational,  and  we  are  in 
touch  with  Collins  regarding  details  of  arranging  to  run  station 
software  on  it.  This  will  give  Collins  a  local  PR  net  testbed, 
allowing  much  better  checkout  of  PR  software  before  release,  and 
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mutual  debugging  by  BBN  (via  cross-net  debugger)  and  Collins 
(locally)  when  this  is  appropriate. 

5.5.  BBN  Service  Hosts 

During  this  quarter,  BBNA  was  down  solidly  for  two  days  in 
May  with  hardware  problems.  Also  slowing  progress  (on  TCP  in 
particular)  was  a  rash  of  hardware  problems  on  the  new  stand 
alone  test  machine,  BBNF .  These  included  problems  with  network 
interface  hardware,  somewhat  difficult  to  separate  from  software 
(i.e.,  TCP  integrated  into  the  monitor)  problems.  All  BBNA  and 
BBNF  hardware  malfunctions  had  been  corrected  by  the  end  of  the 
quarter. 


20 


